Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000085_owner-urn-ietf _Fri Mar 28 17:06:37 1997.msg

Internet Message Format | 1997-04-01 | 10KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id RAA05501
    for urn-ietf-out; Fri, 28 Mar 1997 17:06:37 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id RAA05496
    for <[e-mail]>; Fri, 28 Mar 1997 17:06:34 -0500 (EST)
Received: from beach.w3.org by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA18384  (mail destined for [e-mail]); Fri, 28 Mar 97 17:06:31 -0500
Received: from beach.w3.org (beach.w3.org [207.8.37.250])
          by beach.w3.org (8.8.4/8.8.4) with SMTP
      id QAA14589; Fri, 28 Mar 1997 16:06:26 -0600
Message-Id: <[e-mail]>
Date: Fri, 28 Mar 1997 16:06:25 -0600
From: Dan Connolly <[e-mail]>
Organization: World Wide Web Consortium
X-Mailer: Mozilla 3.01 (X11; I; Linux 2.0.27 i586)
Mime-Version: 1.0
To: "Ron Daniel, Jr." <[e-mail]>
Cc: [e-mail]
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
References: <[e-mail]>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: [e-mail]
Precedence: bulk
Reply-To: Dan Connolly <[e-mail]>
Errors-To: [e-mail]

Ron Daniel, Jr. wrote:
> Some of your comments should probably be directed to
> the THTTP draft instead.

I think so too.

> >My intuition says that we're after a fiarly small set
> >of primitives that doesn't need to be expanded:
>
> I think it is fairly small, but I'm unwilling to assume it won't need
> to be expanded.

Hmm... we just disagree. Any other opinions?

I suppose the burden of proof is on me to show that the list
has an end. Hmm... I can't come up with anything
beyond an aesthetic arguments: there seem to be
five sorts of things: names (N), locations (L), identifers (I),
resource instances (R) and URCs (C). It seems like there are only
finitely many interesting permutations. In regexp terms,
the set looks like:

    [NLIRC]I?2[NLIC]s?

Say... that reminds me: what about C2R, C2I, C2N, C2L?
i.e. given a URC (aka a description or query) return
one (or a set of) resource instances, identifiers, names,
or locations? Seems like a lot of search and directory services
(and HTTP/HTML forms) offer those services. The WEBDAV
group is considering standardizing a convention for
such an operation in HTTP.

Anyway...

If the list is extensible, it's extremely important to
specify what to do when you find an unknown operation and in
general, how new operations get deployed. I'll
have to look at the NAPTR draft etc. to be sure this
is covered.


> >Note that N and L are both URIs. Hence my second point:
> >the distinction between URNs and URLs isn't necessary.
>
> Yes and no. Both are URIs, so an I2I method would suffice at that level.
> However, this group distinguishes between names and addresses.

Yes, there are very useful _extrinsic_ distinctions between names
and addresses: external to the identifier, there might be
information that suggests it can be resolved or not, etc. I just
object to a separation of the space of URL schemes and
the space of URN schemes and to the separation of URL syntax
from URN syntax.

> If I have
> a name and want to get an address, we need an N2L operation.

I don't dispute the utility of a N2L operation: I just don't
see any reason to restrict the input to URNs.
The N2L operation captures the very useful
"located-at" relation, e.g. document X is located at Y. But
is there some reason to disallow something like the following?

    N2Ls(ftp://ds.internic.net/rfc/rfc1866.txt)

Seems awfully useful to me to find all the replicas/variants of
rfc1866 known to some service. Is one of the other operations
intended to cover this question?

> >> 4.2 N2Ls (URN to URLs)
> >> This operation is used to map a single URN to 0 or more URLs.
> >
> >
> >This one becomes:
> >       Given a URI N, Return a set of URIs L[i] such that there
> >       is a link from N to L[i] of type "N2L" for each i.
>
> I'm sorry Dan, but I really don't see the benefit of your suggested
> rewordings.

It's mostly a matter of taste. But there is a little substance
to it: I expect this document to specify not just black-box
operations, but also some properties of those operations that
relate the operations to each other.

For example, there seems to be, latent in the services-01 draft,
a relation
    N2L <: URI x URI
that relates the N2L and the N2Ls operations: if computing
N2L(n) yields l, then the pair (n,l) is in the N2L relation;
meanwhile, if N2Ls(n) yields l[i], then (n, l[i]) is in the N2L
relation for each i. This connection is implied by the naming
etc., but not specified explicitly anywhere.

There are all sorts of issues around authenticity, consistency,
freshness, and all that which fall outside the scope of this
sort of specification. But there are _some_ semantics
of the N2L and N2Ls operations that can be specified, no?


> >> All URIs shall be encoded according to the URI specification [6].
> >
> >I can't find reference 6. I'm terribly curious to know which
> >document you're citing for URI syntax.
>
> RFC 1630 is what we normally use, I'm not sure if that is what Michael
> was intending to cite or not. (The problems with preparing a draft
> right before the deadline).

RFC1630 is informational, not standards track. I suggest you
cite either the url syntax draft, or RFC1808, which I expect
will be updated/replaced by the ultimate url syntax draft.


> >It has another parameter though: the metadata schema
> >that the URCs should conform to.
> >
> >Hmm... I'll have to look closely at THTTP to see if
> >it's gratuitiously different from PICS.
>
> THTTP says that people should use format negotiation if they want
> a partiular format. We are not defining the one true URC format.

Sure... but the MIME type of the result isn't the same as
the schema. Lots of metadata schemas can be represented
as text/sgml. Or do you intend to fold the mime-type axis
and the schema axis into one?

And about PICS... it specifies ways to encode metadata
requests into HTTP GET operations. Seems to me THTTP is
doing the same thing. If they can do it the same way,
that seems like a Good Thing. I still haven't gotten
around to THTTP yet.


> >Something that I think should be specified: is L2N expected
> >to be the inverse of N2L?
>
> Nope. If a resource has multiple URNs and URLs, I don't think we should
> mandate any particular behavior on the part of resolvers to make stronger
> mappings between the identifiers.

I said 'expected,' not mandated. You really mean that there's
no relationship whatsoever between the N2L and the L2N operations?

> >> 4.8 L2Ls (URL to URLs)
> >> This operation is used to discover URLs that are considered equal to each
> >> other.
> >
> >This one is clearly supposed to be an equivalence relation.
> >If N2N is also an equivalence relation, then I don't understand
> >the distiction.
>
> See earlier discussions on names vs. addresses.

I don't see that it applies. Could you elaborate?

If there's an I2I operation, why is L2L necessary? why is
N2N necessary? It seems clear to me that if n is a URN
and l is a URL, then you can be certain that I2I(n) won't
return l and vice versa.

The relationship between two URLs that are equivalent
is identical to the relationship between two URNs that
are equivalent. What motivates three different operations
to deal with this one relationship?


> >       S2D(URI S, URI T) -> set of URIs D[i]
>
> Hmmm, sounds pretty good. The first question that comes up is that
> sometimes we are happy mapping from one URI to another, and other times
> we want to get back a specific type of URI (URN or URL). So, we need to
> modify your earlier definition and this suggestion for the generic
> operation.

I'll buy that; so you might call them IT2I, IT2L, and IT2I.
(for identifery/type to identifer, ...).


> >> 4.10 I2I (URI to URI):
> >> This operation is used to map any arbitrary URI to any other arbitrary URI.
> >
> >Again, I don't see the reason for more than one equivalence
> >relation.
>
> Please reconsider this in light of this group's axiom that URNs and
> URLs are both URIs, but are not equivalent.

I see that; but it doesn't motivate more than one equivalence
relation. I'll try yet another argument:

Suppose we had relations:
    N2N <: URN x URN
and
    L2L <: URL x URL

If the intersection of URNs and URLs is empty (fair assumption?)
then N2N and L2L don't intersect. So one relation I2I that
is the union of L2L and N2N holds all the information from
both relations without creating any ambiguity.


> >> 4.11 I=I (Is URI equal to URI):
> >> This operation is used to determine whether two given URIs are
> considered to
> >> be equal by the server being asked the question.
> >
> >And again.
>
> Um, are you sure about this Dan? This isn't requesting that a mapping
> be performed, its a predicate on the existance of such a mapping.

Ah... no, I was confused. I see now.

But again: the relationship between I=I and I2I should be
specified, but isn't. For example, if I2I(x) yields y, then
I would expect I=I(x,y) to return true, right?

--
Dan Connolly, W3C Architecture Domain Lead
<[e-mail]> [phone]
http://www.w3.org/People/Connolly/
PGP:EDF8 A8E4 F3BB 0F3C FD1B 7BE0 716C FF21